m, n は row, col との対応が分かりにくいので、num_rows, num_cols などと置くといいのではないでしょうか。

採用させていただきました

obstacleGrid の要素が 0 あるいは 1 であることを利用した算術による初期化で、ちょっとトリッキーに感じました。例えば障害物の有無を文字列で表すようになったときなど、仕様変更にも弱いように見えます。私がいまパッと書け、と言われたら次のようにします。

偉そうなことを言いながらあんまり上手く書けている気もしないのですが、「左隣 col-1 を引き継ぐ。ただし障害物があったらそこから先はゼロ」感が出るとよいのではないでしょうか。

かなり書き方の幅が広いように思うので、もうちょっと他の人の書き方を漁ってみても良さそうです。

アドバイスを参考にして以下のように書き直しました。（ほぼ同じですが）

        EMPTY = 0

        if obstacleGrid[0][0] != EMPTY:
            return 0

        unique_paths_per_row = [1] + [0] * (num_cols - 1)

        col = 1
        while col < num_cols and obstacleGrid[0][col] == EMPTY:
            unique_paths_per_row[col] = 1
            col += 1

path と way は同じ意味で使っているので、英単語も揃えたほうが分かりやすそうです。

配る相手セルが障害物で潰れているかどうかは、ここでは気にしなくて良さそうです。

なるほど、配る側のセルになったときに0になるので処理が重複していましたね

メモリ使用量が増えるのをやむなしで、2次元配列（フルのテーブル）で書いたほうが、配るDPは分かりやすいと思いました。また、最終行は配らなくていいとか、障害物があったら0に潰して配れない（こっちは最終行も処理する必要がある）、など制御が比較的面倒で、配るよりも貰う方が書きやすそうに感じました。

「配るよりも貰う方が書きやすそう」は同意します。
配るDPでも直前の二行を保持しておけば良いので、一次元にする必要はないのではないかとと個人的には思います。

配るDPでも直前の二行を保持しておけば良いので、一次元にする必要はない

そのとおりで、処理的には問題ないのですが、書きやすさ（バグの埋め込みやすさ）・読みやすさの観点からは、2次元配列の方が優れていそうだな、と感じました。unique_paths_per_row と unique_paths_next_row の入れ替え（更新）の必要がなかったり、最終行は入れ替えしないという条件が理解しやすかったりしそうです。